Columbia Kermit/kermit.zip/newsgroups/misc.20000824-20010305/[e-mail] _Mon Oct 16 22:16:26 2000.msg

Internet Message Format | 2020-01-01 | 7KB

Return-Path: <[e-mail]>
Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
    by fozimane.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA07014
    for <[e-mail]>; Mon, 16 Oct 2000 22:13:03 -0400 (EDT)
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id WAA26290
    for <[e-mail]>; Mon, 16 Oct 2000 22:09:45 -0400 (EDT)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id VAA14433
    for [e-mail]; Mon, 16 Oct 2000 21:46:35 -0400 (EDT)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: "Steve" <[e-mail]>
Subject: Re: No Carrier
Message-ID: <3bOG5.57125$[e-mail]>
Organization: Giganews.Com - Premium News Outsourcing
Date: Tue, 17 Oct 2000 01:45:36 GMT
To: [e-mail]

Sounds like we need to rethink the plan of attack here...

In the short term, is there any easy way around the No Carrier when we send
a Finish from the client?  A setting on the host or a modem initialization
setting on the client?  I cant see where putting multiple servers in the
host script is going to work.

Thanks,
Steve

Frank da Cruz <[e-mail]> wrote in message
news:8sfp3o$14n$[e-mail]...
> In article <%ZHG5.54658$[e-mail]>,
> Steve <[e-mail]> wrote:
> : We currently have DOS clients that on a regular basis, communicate with
a
> : host PC to exchange files.  The clients and the host are running DOS
apps
> : that call Kermit 3.15.  We would like to upgrade the host to K95 to
allow
> : for multiple transfers at one time on one PC.
> :
> : Here is what we are doing:
> : The host waits in server mode for a client to connect.  The clients
connects
> : either through a serial cable or modem...
> :
> So then you need one serial port for each simultaneous session.  As you
know,
> PCs are not easily able to accommodate more than two serial ports, due to
> the severe shortage of available IRQs in the PC architecture.  Any serial
> ports beyond two are likely to introduce interrupt conflicts.
>
> : ... and sends across a file that contains
> : a field that tells the host which client this is then the client sends a
> : Finish command to kick the host out of server mode.  The host opens the
file
> : to get the client ID then changes to a directory containing files
specific
> : to that client that are waiting to go to the client, compresses the
files
> : and sends across the compressed file.  The host then goes into server
mode
> : waiting for the clients compressed data file.  After the client sends
the
> : file it sends a Finish command and the host uncompresses the file and
> : processes the data, copying files contained within the compressed data
file
> : to the appropriate places.  The host then goes back into server mode
waiting
> : for the next client.
> :
> All this switching into and out of server mode sounds pretty tricky to me.
> How do the two sides stay synchronized?  Wouldn't it be better to keep the
> host in server mode and drive everything from the client script?
>
> For example, make the client ID correspond to a directory on the host.
> Then the client script could:
>
>  . CD to its own host directory.
>
>  . Does a GET command for the files that are waiting.  Note that both
>    K95 and MS-DOS Kermit 3.15 have a RETRIEVE command, which means
>    "send me the specified files, and then delete each one if and only
>    if it is sent successfully" (in K95, this is equivalent to GET
/DELETE).
>    This feature is designed for exactly your kind of application.  For
>    more discussion of "atomic file movement", see:
>
>      http://www.columbia.edu/kermit/case10.html
>
>  . I would guess that the compression step can probably be skipped, since
>    the modems take care of that transparently.  In those cases where you
>    might not have a data-compressing modem connection, the improved
>    simplicity might be worth the tradeoff.  Conversely, you have have the
>    client script obtain send "remote host zip" or similar commands.
>
>  . Now the client sends back its files and sends FINISH, and hangs up its
>    connection.
>
> This makes the server end quite simple.
>
> : One other important part is from time to time a phone
> : line can go bad in the middle of a transfer and therefore for example
the
> : host may be waiting for the clients compress data file while a new
client
> : may be connecting and sending the client ID file.
> :
> This, of course, points up the dangers of using a DOS/Windows server,
which
> has no notion of separate user identities or authentication.  You would
solve
> an awful lot of programs by using some form of Unix (such as Linux or SCO)
> on the server.  This gets you user IDs, file protection and permissions,
and
> all the rest automatically, not to mention the natural ability of the
Kermit
> server to run subprocesses without hanging.
>
> : We refer to this as the
> : client and the host being out of synch.  To resolve this, when the
client
> : first connects, it sends 2 Finish commands which 100% guarantees that
the
> : host will be at the "waiting for client ID" section of the host app as
that
> : part of code on the host looks something like:
> : Do While True
> :  Kermit server
> :  If File(ClientID)
> :   Exit Do
> :  End If
> : End Do
> :
> : We would like to upgrade the host app to K95 and have a VB app that
seems to
> : work fine except for communicating over the modem.  When we send the
Finish
> : from the client, it drops the line and we get No Carrier on the client.
If
> : we could get around this, that should solve our issue.  I am not sure
> : changing the software on the client is a realistic option as updating
the
> : clients is a major hassle.
> :
> Still, it might be worth it.  The current scheme has too many
vulnerabilities,
> both procedural and security-related.
>
> : We can change the modem initialization string on the clients so that is
an
> : option.
> :
> : Any thoughts?
> :
> It's up to you.  If you can't change the client scripts, then you'll need
> to make the server script take every possibility into account.  If you
want
> to continue with your current scenario, Jeff already made the suggestions
> you need -- remove the EXIT command from your script, and have the script
> loop back and wait for another call.  Or put two SERVER commands in a row.
> Whatever you need to do, the scripting language will allow -- you just
need
> to think through all the possibilities.
>
> Another possibility is to simply run K95 host mode on server:
>
>   http://www.columbia.edu/kermit/k95host.html
>
> In that case, the client script has to log in and negotiate the menus, but
> that's not too difficult, and then at least you have some measure of
> authentication and file protection.
>
> - Frank